An operating system image interacts with hardware in a computer to perform a multitude of functions. Conventional computers generally execute the operating system to manage various aspects of the computer as it is running. Typically, the operating system is responsible for managing access to storage devices as well as input and/or output devices, and controlling the execution of one or more additional applications. Before the operating system may be executed by the computer, it typically must be installed on the computer, a process which usually involves copying multiple files from a distribution medium (e.g., a CDROM) onto a storage device (e.g., a hard disk) of the computer.
A typical operating system includes a large number of files which may include instructions and/or data. These instructions, when executed by the computer, provide the operating system functionality. The operating system may be modified (e.g., updated) in any of a wide variety of manners, such as by adding or replacing one or more particular files, by any of a wide variety of people (e.g., a user, administrator, software developer other than the operating system developer, etc.). It becomes difficult to troubleshoot a malfunctioning computer or update the operating system because it is difficult for the user or administrator to know exactly what functionality is or should be installed on the computer.
In existing systems, servicing the binary files that comprise a software product (e.g., the operating system or an application program) is often the most expensive aspect of a software product lifecycle. An exemplary software product lifecycle includes a pre-deployment phase (e.g., pre-installation), a deployment phase (e.g., installation), and a post-deployment phase (e.g., on the running system). The size of the binary files, the amount of binary files that are typically serviced for any single problem, and the different locations of the binary files during each of the software product lifecycle phases make the distribution and creation of the binary files difficult. Also, servicing multiple binaries across the system fails to provide specific information on the current version of any larger aggregated piece of functionality on the system.
For example, when creating a service package to remedy an issue in software code stored in a binary file, existing systems typically create an updated copy of the binary or a patch that modifies the software code without modifying other software. However, existing systems typically require different versions of both the patches and the binary files based on the current phase of the software product lifecycle: one version for pre-deployment, one version for during deployment, and one version for the running system.
In another example, some prior systems provide a “hot” fix (e.g., a patch) for the end user that replaces a single file or library (e.g., library.dll) on a running system or during predeployment. Other systems provide updates during installation by directing the client machine to obtain the updated file or library (e.g., library.dll) from an installation medium or via a network and install the obtained update. However, such systems require separate scripts for each lifecycle phase of the client machine: pre-deployment, deployment, and post-deployment. Further, a change to a single file may necessitate a change to other dependent files. The prior systems fail to provide for intelligent dependency resolution during the update process.
Accordingly, a system for servicing a software product across the entire software product lifecycle is desired to address one or more of these and other disadvantages.